Stellar testnet build · contracts live, one settlement proven on-chain Explorer ↗
Parallar
How it works The rule The proof Architecture Risk engines Partnerships Instruments On testnet
Documentation Open the app
The first private protection protocol on Stellar
Private protection for tokenised assets.
Buyers cover a position against a parametric trigger: a missed coupon, a breached index. Underwriters fund a fully-collateralised reserve and earn the premium. When a covered trigger fires, payouts settle through a zero-knowledge proof, not a claims process.
How it works See it running on testnet
Fully collateralised· Private positions· Proof-settled· Permissionless
3
Instruments deployed
1
Settlement proven on-chain
ZK
On-chain verifier
Stellar
Network · testnet
Overview
One reserve. Two ways in.
Protection is a market between the holders who want cover and the underwriters who back it. Parallar runs both on-chain, and settles between them by proof.
For asset holders · buy cover
Protect a tokenised asset
Hold a tokenised asset and worried about a loss event? Buy cover and pay a premium. If a covered trigger fires, you are paid from the reserve. The amount is fixed by a published formula and a proof.
Automatic, proof-settled payout when the trigger fires. No claim to file.
Your position is committed on-chain; confidential cover keeps the totals private too.
Backed by reserves that are funded before any cover is sold.
For asset holders ›
For underwriters · provide the reserve
Back the protection, earn premiums
Supply the collateral that backs payouts and earn the premiums buyers pay. Deposit into a non-custodial vault. The protocol enforces that total cover can never exceed your reserve.
Earn premium yield from cover buyers.
Non-custodial: only a verified proof can move the reserve, never an operator.
Solvency is enforced on-chain; withdrawals are open outside a settlement.
For underwriters ›
The mechanism
Coverage, settled by proof
No claims department, no committee, no admin key. A default either produces a valid proof, or it does not.
01 / Underwrite
Fund the reserve
Underwriters deposit collateral into a non-custodial vault and earn premiums. Cover sold can never exceed the reserve, checked on every purchase.
02 / Cover
Buy protection
Buyers cover a position and pay a premium. Each position is committed on-chain; confidential cover keeps the size and totals private.
03 / Prove
Settle a default
Anyone runs the settlement program off-chain. It reads the on-chain payment record and proves who is owed, by a published formula, in zero knowledge.
04 / Payout
Verify and pay
The contract verifies the proof on Stellar and releases each payout from the reserve. A verified proof is the only thing that can move it.
The rule
What a settlement actually computes
Every coverage type settles on the same shape. What changes is what the words mean.
A cell defines two quantities for each observation period: what was expected, and what was realised. The gap between them is the loss. A holder is paid their cover scaled by that gap, capped at their cover, and the sum of payouts is capped at the reserve.
For a missed coupon, expected is the amount owed and realised is what actually arrived. For a NAV floor, expected is the attested floor and realised is the observed NAV. For a parametric index, expected is the trigger level and realised is the attested reading. The arithmetic never changes; only the definitions do, and each cell publishes its own before anyone commits.
Realised values are measured carefully. A credit cell counts receipts on an asset-received basis and treats a clawed-back payment as a shortfall rather than a payment. A NAV cell reads only an attested valuation at the stated observation date. The measurement rule is part of the pinned engine, not a matter of interpretation at settlement.
Loss
loss=expectedrealised
$4,770,000$3,290,000=$1,480,000
Payout
payout(holder)=cover(holder)×(loss÷expected)
$25,000,000×31.03%=$7,757,862
Worked above: a missed coupon on a $25m covered position. The percentage is not a judgement about severity; it is the gap the issuer actually left.
Each holder is paid their committed cover, scaled by the realised loss. The sum of all payouts can never exceed the reserve.
Where realised meets or exceeds expected, the loss is zero, every payout is zero, and there is nothing to settle. The program will not produce a proof for a non-event, whatever the coverage type, so no payout can be authorized. Protection that did not trigger cannot be claimed.
The same rule, four coverages
Each cell fixes these definitions at deployment, alongside its engine. Nothing here is decided when a loss occurs.
CoverageExpectedRealisedThe program refuses when
Missed payment
credit · live
The amount owed to holders for the period, fixed by the published schedule
Qualifying payments actually received, on an asset-received basis
Every holder was paid in full, so there is no gap to prove
NAV floor
valuation · specified
The attested floor the asset is covered down to
The attested valuation at the stated observation date
The valuation sits at or above the floor
Parametric index
index · pilot
The trigger level written into the cell
The attested reading for the observation window
The reading did not breach the trigger
Redemption failure
liquidity · specified
The redemption amount due at the request date
The amount actually redeemed within the stated window
The redemption settled in full and on time
The right-hand column is the part worth reading twice. In each case the refusal is not a policy the protocol enforces; it is a computation that has no valid output, so no proof exists to submit.
The proof
What the zero-knowledge proof guarantees
And, just as importantly, what it does not.
What it proves
The proof attests that the published settlement program ran over the supplied inputs and produced exactly these payouts. It binds the result to the positions committed on-chain, to the instrument's pinned rules, and to the payment snapshot it was given. Tamper with any of those and verification fails.
The contract checks a single Groth16 proof using Stellar's native BN254 pairing host function. One verification authorizes the whole settlement.
What it does not prove
A proof guarantees correct computation over the inputs it was supplied, not that those inputs are the canonical truth of the world. The honest trust assumption is the integrity of the payment snapshot fed to the program.
On this build the snapshot is assembled from observed chain data; a production deployment hardens that source. Parallar states this plainly rather than overclaiming that a proof certifies reality.
A settlement, start to finish
One observation period, from a loss event to money leaving the reserve
Nobody in this sequence decides anything. Each step is either arithmetic or a check that fails loudly. The worked figures follow a missed payment; the sequence is identical for every coverage type.
01
The observation period closes
A period ends on a covered asset: a payment date, a valuation date, an index window. What was expected is already fixed by the cell, committed on-chain before any cover was sold.
Expected
$4,770,000
02
The realised value falls short
What actually happened is measured by the cell’s own rule: payments received, an attested valuation, an index reading. Here the issuer paid part of what it owed, and a clawed-back payment would have counted as a shortfall rather than a payment.
Realised
$3,290,000
03
Anyone runs the settlement program
The deadline elapses and any party, privileged or not, runs the pinned program over the cell’s inputs. It computes the loss and every payout, and produces a proof that it did so correctly.
Loss proven
31.03%
04
The contract verifies, then pays
One proof is checked on-chain against the cell’s pinned engine. Five bindings must hold. Only then does the vault release each payout, capped at the collateral behind it.
Paid from reserve
$1,940,000
Elapsed, deadline to payment
Forty-one minutes on testnet, most of it proving. No business hours, no adjuster, no file to open.
What the holder did
Nothing. There is no claim form, because there is no discretion for a form to appeal to.
Had there been no shortfall
The program would have refused to produce a proof at step three, and the sequence would have ended there. That is true of a full payment, a valuation above its floor, and an index reading inside its trigger alike.
Same four steps
A NAV floor
Step one closes on the valuation date. Step two reads the attested NAV against the covered floor. Steps three and four are unchanged: the same program, a different pinned engine, one proof.
Same four steps
A parametric index
Step one closes at the end of the observation window. Step two reads the attested reading against the trigger. Steps three and four are unchanged: the gap is measured in index units rather than currency.
Same four steps
A failed redemption
Step one closes when the redemption window expires. Step two reads how much was actually redeemed against what was due. Steps three and four are unchanged: a partial redemption pays pro rata, exactly as a partial payment does.
How it compares
Settled by proof, not by discretion
Protection over credit is not new. What is new is who is allowed to decide a payout.
Who authorizes a payoutPositionsFundingPortable
Parallar a verified proof, no party can override confidential (commitments only) funded by construction (cover ≤ reserve) yes, an on-chain asset
DeFi cover mutual a discretionary member vote public shared pool, discretionary limited
TradFi CDS desk a committee plus a counterparty promise private, off-chain counterparty credit OTC, bilateral
Embedded tranche the issuer's capital structure n/a structural subordination non-portable
A claims committee can be convinced to pay a default that never happened. This guest cannot: feed it a fully-paid epoch and it panics on honest data. A false claim is unprovable, by construction.
The architecture
One generic core, every instrument
Four contracts, separated on purpose. Each instrument is an instance, not a fork.
01
Factory and registry
A registry holds instrument types; the factory deploys an instance by cloning a generic vault and settlement contract and cross-binding them. Adding a second instrument is one transaction.
02
Vault
Holds the reserve and the private cover commitments. Deposits and withdrawals are open; only a verified settlement can move funds to a payee. Solvency is enforced on every purchase.
03
Settlement
Verifies one proof against the instrument's pinned image id, checks the bindings, and executes the payouts. No admin path, no pause-and-pay, no override.
04
Guest program
The per-type rules, compiled to a zkVM image. New rules mean a new type entry with a new image id; live instruments stay pinned to theirs forever. Rules are never upgraded in place.
Guarantees · what cannot happen
No payout without a verified proof
No getter that pays from public state, no plaintext cover, no settlement override. Verification is the sole authorization.
One settlement per epoch
An epoch settles once. Replaying the same proof, or settling before the deadline, reverts.
A non-default cannot be claimed
If the trigger did not occur, the program produces no proof. There is no input that fakes a default into existence.
Payouts cannot exceed the reserve
The sum of payouts is capped at the collateral, and stale or tampered roots are rejected at verification.
The risk-engine estate
Machines that price risk, built to show their work
Every number checkable· Every model versioned· Every assumption disclosed
Before Parallar sells protection on a tokenised asset, three questions need answers: how exposed is this asset, what is fair protection worth, and what does the market think? Each answer is computed by a certified engine, and every number comes with a cryptographic receipt showing exactly how it was made.
How exposed is this asset?
An engine reads the obligated party's own numbers the way a seasoned underwriter would: leverage, earnings, cash flow, payment history. From these it scores the chance of a covered event. A built-in safety rule stops it from ever calling anyone "too safe to fail."
Fundamentals engine
What is fair protection worth?
A second engine turns that risk score into a fair annual price for protection, priced the same way the professional credit-insurance market does it. Safer asset, cheaper protection; riskier asset, dearer.
CDS pricing engine
What does the market think?
Where a real market quote exists for the same name, a third engine reads it as a second opinion and blends it in. The recipe for the blend is published, never improvised.
the market benchmark & blend engines
The five engines
EngineWhat it doesStatusAccuracy check
Fundamentals
v2 · cohort-anchored
Reads the obligated party's own numbers and scores the risk, anchored to decades of real-world default history by credit grade. A good story can tilt the score but never rewrite the base rate. built · cert pending exact
CDS pricer
route A
Turns the risk score into the fair price of protection, using the same two-sided arithmetic the global credit-default-swap market runs on. The asset's terms are inputs; the method never bends per deal. built · cert pending exact
Market benchmark
credit triangle
Reads a real, timestamped market quote and converts it into the market's own implied view of the risk. Kept clearly separate from the model's view: a second opinion, honestly labeled as one. built · cert pending 1 in 1bn
Blend
§2(d) · 70 / 30 pinned
Combines the model's view and the market's view into one number, with the mixing recipe (70% model / 30% market) published and fixed. An asset with no market quote keeps its model score. Nothing is invented. built · cert pending exact
Portfolio
live engine
The engine already running behind the live testnet: it turns the whole covered book, across coverage types, into a premium, an expected loss, and a worst-case reserve. These are the numbers a settlement actually pays on. live on testnet matched twin
The safety floor, visibly
Chance of a covered event in a year, before and after the anchor
A model looking only at financial statements can talk itself into absurd confidence: odds of 1-in-a-million for a spotless balance sheet. The anchor forbids that: nothing scores better than the safest credit grade's real historical base rate. Ordinary and troubled assets are barely moved.
Archetypev1 · raw logisticv2 · cohort-anchored
investment grade0.012 bp2.02 bp
strong0.13 bp5.14 bp
mid1.370%1.359%
stressed99.99%99.98%
near-default99.998%99.996%
The same engine, four assets
What protection costs
Protection on a safe asset costs almost nothing per year. On a troubled one, the annual price explodes, and the expected years of premium collapse, because an asset close to failing won't be paying premiums for long. That is exactly how the professional market behaves, which is the point: the engine reproduces it, checkably.
AssetFair spreadRPV01
investment grade / strong< 1 bp4.63 y
mid75 bp4.47 y
stressed40,832 bp0.15 y
near-default43,856 bp0.14 y
One proof. Two chains.
Every settlement boils down to a small sealed receipt, 208 bytes plus a proof, that any chain can check for itself. Stellar checks it and pays out. An Ethereum-style chain checks the same receipt and publishes the verified facts, so lending markets there can rely on them without trusting anyone's word, including ours.
No bridge. No wrapped assets. No oracle committee. Read-only verification mirroring: the mirror is a fact oracle whose facts are proofs.
journal.v1 · 208 B frozen layout · sha256-keyed on both chains · 5-input Groth16 layout shared verbatim
What the receipts do and don't prove
A receipt proves the math was done correctly, by the exact published version of the engine, on the exact data provided. It does not prove the data itself is true (that is a separate, signed attestation), and it does not prove the model is wise.
The example calibrations on this page are realistic illustrations, not fitted to live data. Every prediction is recorded so its accuracy can be checked against reality later. The engines shown as "certification pending" are finished, tested code awaiting their final cryptographic registration.
For practitioners: PD/LGD scorecard with a grade × sector through-the-cycle cohort anchor · ISDA-lineage two-leg CDS pricing on a flat hazard · credit-triangle market-implied PD (risk-neutral, labeled) · pinned log-odds blend with a disclosed Q→P haircut · bit-exact fixed-point↔float parity gates · full specifications in the documentation.
One core, a family of instruments
A settlement rail, not a single product
The settlement core is trigger-agnostic. Credit default on tokenised debt is live; confidential cover, first-loss tranches, protected yield, and weather/index settle on the same frozen surfaces.
Live · proven
Credit default
Cover on a tokenised debt position against a missed coupon or principal payment.
Built
Confidential cover
Position sizes and totals sealed on-chain.
Built
First-loss tranches
Attachment and detachment points on the same core.
Built
Protected yield
A coupon stream with its downside wrapped at source.
Built
Weather and index
Attested readings against a fixed threshold.
Non-custodial and fully funded
The reserve is held in claw-proof, freeze-proof assets. Total cover can never exceed reserves. No one can pull the pool.
Private positions
How much cover each holder buys is sealed on-chain. The protocol enforces the totals without ever seeing the parts.
Permissionless settlement
Anyone can generate a proof and settle. There is no privileged operator and no admin override.
On testnet
Deployed, and proven with a real settlement
This is a hackathon build on Stellar testnet, not a launched market. The contracts are live, and a full default-to-payout has executed on-chain. Verify any of it on the explorer.
Verified on-chain · paid
A holder went unpaid. The reserve paid the cover buyer.
A real default-to-payout on testnet. The settlement program proved exactly what was owed, the contract verified the proof, and the payout left the reserve. The cover amount stayed private throughout.
default proof verified on Stellar payout
EventSettled
Paid to cover buyer800
Reserve after payout200
Authorized byZK proof
NetworkStellar Testnet
Next
Pick your side, or watch it run
For asset holders For underwriters See it on testnet
Parallar
Verifiable settlement on Stellar · testnet build
Protocol
How it works The rule The proof
Participants
For asset holders For underwriters Risk engines Partnerships
Contracts
Factory ↗ Verifier ↗ On testnet